需求傳到工程師手上時，常常已經是三手轉述。把轉述當聖旨的問題不在太聽話，而在於你根本不知道皇帝是誰。

一句「上面說要做」

昨天我們留下一張變更報價單，最後一格是「誰同意」。今天要處理的，就是這一格背後更早的問題：這個需求，到底是誰說的算？

先講故事。案例照舊經過去識別化與合併改寫。

某個系統整合案進行到中期，客戶窗口在例行會議上帶來一個新需求：

「上面說，想要一個儀表板，隨時看得到各案的進度。」

「上面」兩個字一出，會議室的空氣就變了。沒有人問「上面是誰」，沒有人問「原話是什麼」，更沒有人問「為什麼想要」。PM 當天開了 Ticket，標題就叫「主管儀表板」。

團隊做得很認真。挑了圖表元件、設計了燈號、進度做成即時更新，工程師還自主加班，把畫面調到投影在會議室大螢幕上特別好看。做了一個月。

成果會議那天，客戶端真正的主管第一次看到這個功能。他盯著滿螢幕的圖表看了一陣子，說了一句：

「這不是我要的。」

他要的，是每週一早上有一頁摘要告訴他哪幾個案子快出事、需要他出面。他不登入系統，未來也不打算登入。即時、圖表、燈號，全部不在他的想像裡。

會議室安靜下來的時候，另一件事也浮出來了：儀表板上的進度，得靠各案承辦人員每天手動更新欄位才會是真的。而這群每天要「餵」這個系統的人，從頭到尾沒有被任何人問過一句。

當時團隊怎麼理解這件事

當時團隊的理解大概是這樣：

窗口就是客戶，客戶說的就是需求；需求上面還掛著「上面說」，那更沒有討論空間了——聖旨欸；我們能做的就是把東西做好做漂亮，做得越用心，越能證明我們的專業。

每一句單獨看都有道理。合在一起，是一個月的重工。

問題出在第一句。窗口不是客戶，窗口是離你最近的那個人。他負責傳話、安排會議、催進度，但他不決定需求、不使用系統、不付維護資料的成本，通常也不負責驗收。把「離你最近的人」當成「說了算的人」，是需求事故裡最常見的一種。

至於「聖旨」——回頭看那句需求的旅程：主管在某個場合說了某句話（原話已不可考），窗口理解成「要一個儀表板」，PM 轉述成一張 Ticket，工程師把 Ticket 讀成「即時、圖表、投影好看」。每一手都補上一點自己的詮釋。傳到最後，聖旨上的字沒有一個是皇帝寫的。

五個問題，五個不同的人

這次缺席的工程責任，叫做 Stakeholder（利害關係人）識別。它可以縮成五個問題：

誰提出？    最早說出這個需求的是誰、原話是什麼
誰決定？    誰有權加它、改它、砍它
誰付成本？  上線之後，誰要為它多做事
誰使用？    每天真正操作它的是誰
誰驗收？    最後誰判定通過、拿什麼判定

這五個問題，很多團隊會用同一個名字回答：「客戶」。但在開場的故事裡，答案是五個不同的人。

提出的是窗口，而且是轉述加詮釋；決定的是那位主管；付成本的是每天要更新資料的承辦人員；使用的——照原始想像是主管，實際上天天碰這個系統最多的也會是承辦人員；驗收的又是合約上的另一個單位。

五個角色，團隊只見過第一個。

順帶說一句，這不是敏捷或瀑布的選邊題。瀑布用它的方式回答這五問：需求訪談要找到有權拍板的人，需求基準要由決策者確認，驗收依據要先寫清楚。敏捷用另一種方式回答：要求有一個真的被授權做決定的人持續在場，並且把東西做給真實使用者看、拿回饋。兩邊都沒有一條規則叫做「窗口說了就開工」。

這個團隊一樣是兩邊都沒做：需求來源是聽說，決策者第一次看到成品是在成果會議，使用者則是上線後才被通知。

大神腦袋裡藏了什麼

比較尷尬的是後來的檢討。有人翻出更早的另一個案子：一樣是窗口帶來「上面說」的需求，一樣做了不短的時間，為什麼那次驗收一次過？

當年經手的資深工程師想了想，說：

「那次我有先打電話。」

他收到「上面說」的需求時，私下多做了兩件事：找客戶端熟識的人求證，「上面」到底是誰、原話大概是什麼；再找第一線的人聊十分鐘，問他們現在怎麼做這件事。兩通電話，Ticket 上一個字都沒有。

換句話說，那個案子的 Stakeholder Map 其實存在——存在他的通訊錄和人情帳戶裡。組織看到的是「窗口開需求直接做也沒出事」，於是這次照做。只是這次，他在忙別的案子。

流程沒有變好也沒有變壞，只是這一次，沒有人代替流程去問。

這次到底誰在吸收代價？

老規矩。需求被推翻，功能重做，這個代價記在誰的帳上？

Scope       □   一項都沒少，只是先做了一個錯的版本
Time        ■   重工一個月，時程整段後移
Cost        □   沒人提追加，加班照例不記帳
Quality     □   這次還輪不到它
Risk        □   沒有人重新評估
人          ■   一個月的用心白做，再加一個月趕工   ← 還是這格

值得注意的是那一個月重工的「認真程度」。團隊不是隨便做做——他們加班、琢磨細節，把錯的東西做得很精緻。方向錯的時候，用心是乘數：做得越好，丟掉越痛。

找錯了說了算的人，之後的每一分努力，都在替錯誤加碼。

如果沒有大神，應該留下什麼

那兩通電話應該變成什麼？不是一份三十頁的利害關係人分析報告。是在開工之前，團隊能一起把五個問題的答案寫下來——寫不出來的格子，就是該去問的地方。

三個常見的陷阱要特別留意。

第一，「誰提出」那格要寫得出原話。寫不出原話，代表你拿到的已經是詮釋；詮釋要回去求證，不是拿來開工。

第二，「誰決定」那格不能寫「上面」。上面不是一個人名。這格填不出具體的人，之後任何「做完了」都只是猜測通過。

第三，「誰付成本」跟「誰使用」常常是最沒聲音的人。他們不會出現在會議裡，但功能活不活得下來，靠的是他們。開場那個儀表板後來勉強上線了一陣子，因為承辦人員沒時間天天更新欄位，一個月後上面全是過期資料。沒有被問過的人，會用不配合投票。

今日 Artifact｜Stakeholder Map 最小版

把五個問題收成今天的 Artifact。任何需求開工之前，五行填完：

□ 誰提出：最早由＿＿＿＿說出，原話是「＿＿＿＿」
□ 誰決定：加、改、砍這個需求，要＿＿＿＿點頭
□ 誰付成本：上線之後，＿＿＿＿要多做＿＿＿＿
□ 誰使用：每天實際操作的是＿＿＿＿
□ 誰驗收：由＿＿＿＿依＿＿＿＿判定通過

五行填出五個不同的名字，很正常——那正是你需要這張表的原因。真正的警訊是另一種：五行填的都是同一個人，而那個人是窗口。

今日一句

工程師收到的往往不是需求，是需求的三手轉述；把轉述當聖旨，等於讓傳話的人替決策的人蓋了章。

找到說了算的人，需求才第一次有了可以談的對象。至於怎麼談——

明天講專案管理的第一課。不是排程，是談判。